The use of networked electronic devices has become increasingly more prevalent. In the field of home-networks, remote user interfaces are provided for consumer electronics (CE) devices in UPnP (Universal Plug and Play) networks. Remote user interfaces enable the user to remotely control applications on other UPnP devices via a UPnP home network, and also to interact with Internet services using CE devices that are connected to the Internet. An example of such Internet service is one from which the user can download content information, such as movies. For more background on UPnP, see, e.g., WO 2005/002139.
In view of the multitude of providers of Internet services, the different types of services and the multitude of consumer device suppliers involved, it is preferable to standardize the communication protocols and user interfaces as much as possible so as to provide the best experience for the user.
One such standard is CEA-2014 (also known as Web4CE), a Consumer Electronics Association (CEA) standard. See, e.g., “Web4CE: Accessing Web-based Applications on Consumer Devices”, W. Dees and P. Shrubsole, WWW 2007/Poster Paper, Topic: Systems, pp. 1303-1304. The standard specifies a web-based protocol and an XHTML-based content format referred to as CE-HTML, for remote user interfaces on UPnP networks and the Internet. CE-HTML is based on common open Internet languages such as Javascript 1.5, XHTML 1.0 and CSS TV Profile 1.0. CE-HTML specifies the content format and scripting semantics for the interactive services, and defines the browser environment that will host and render those services. The standardization of the current version of CE-HTML is mainly driven forward in two standardization bodies, namely in the Consumer Electronics Association (CEA) and in the Open IPTV Forum (OIPF). CEA-2014 has two main applications: first it allows consumers to remotely control applications on other UPnP devices over a UPnP home network. Second it allows consumers to interact with Internet Services or web-based applications using consumer devices that are connected to the Internet. The user interaction may take place using just the remote control, the keys or the touch screen of the device containing a CEA-2014 compatible browser, e.g. a Media Adaptor, a TV or a mobile phone.
Typically, a web browser is used to render an electronic document in HTML format, but a host of special-purpose languages has been developed to control the browser's operation via executable content embedded in the HTML document. The executable content adds, e.g., interactivity and automation to the browser. Examples of these special-purpose languages are: ECMAScript, a versatile procedural scripting language superficially resembling Java; Cascading style sheets (CSS), which enable style metadata to be abstracted from content; XML, which can be used for content in conjunction with style metadata, as an alternative to HTML; and XSLT, a presentation language that transforms XML content into a new form. Techniques have evolved that involve the combination of XML and JavaScript scripting to improve the user's subjective impression of responsiveness. The Document Object Model standard ensures that all browsers respond in a predictable manner to the same JavaScript (Source: Wikipedia). Furthermore, the browser environment can be extended by a plug-in to display and/or interact with foreign content, such as Adobe Flash. Foreign content may be visual or non-visual and may offer a scripting API that can be used by the scripting engine. Accordingly, a web browser provides a client-side runtime environment for web applications and for executing scripts embedded in an electronic document, e.g., downloaded from a server. For more background on scripting, also see, e.g., WO 2006/106414.
A script embedded in the electronic document may be abused by the document provider to tamper with the system onto which the document has been downloaded or to obtain privacy-sensitive information about the system's user. That is, executing a script received in a downloaded document may hamper the system's security and the user's privacy.
The paper “Secure Web scripting”, V. Anupam and A. Mayer, Internet Computing IEEE Vol. 2, issue 6, November/December 1998, pp. 46-55 discusses an explicit security model. The model proposed has been implemented for JavaScript in the Mozilla browser source code. It is realized by a “safe” interpreter and based on three basic building blocks: access control, independence of contexts and trust management. Access control regulates what data a script can access on a user's machine and in what mode. Independence of contexts ensures that two scripts executing in different contexts (for example, simultaneously in different browser windows or sequentially in the same browser window) cannot access each other's data at will. Trust management regulates how trust is established and terminated among scripts executing simultaneously in different contexts. Different users require different degrees of privacy and security, which translate to different degrees of flexibility when interacting with a Web server. These differences can be expressed in different, user-chosen security policies. The security policy chosen provides for padded cells for scripts. By means of partitioning the name space into inaccessible, read-only and writable items, access control ensures that scripts only have access to those parts of the browser- and window related data that do not compromise a user's privacy while browsing. The security policy also regulates access to external interfaces. Furthermore, independence of contexts ensures that there are no “hidden channels” among scripts in different contexts. For example, if a writable item persisted across changes of context (as is currently the case in JavaScript), it could be used as a user-invisible (albeit non-persistent) “cookie” accessible to collaborating Web sites. Data provided by a user in a first context of a certain window (for example, by filling out a form in this context's HTML document) is only available to scripts in a second context, if the second context is in the first context's access control list (ACL). Scripts in any other context however, are not able to access this data.
WO2006/106414, mentioned above, discusses domain security with script objects. This publication discloses a method of providing domain security with script objects. The method includes generating an exception when a first script object with a first owner attempts access to a second script object with a second owner, generating a dialogue to the second owner querying for the grant of access rights to the second script object, and carrying out instructions whether to grant the first script object access rights to the second script object. The instructions are responsive to the generated dialogue to the second owner. As to the term “owner”: the owner of an electronic document is a domain that issued the document. The owner of any object which represents a local resource (e.g., a client database or file) is a local user. As known, an exception within this context is the occurrence of a condition that changes the normal flow of the execution of software instructions. The computer code designed to handle exceptions is referred to as an “exception handler”.
WO 2005/031568 relates to presenting remote and local services and information in the same user interface by means of a web browser. The web browser contains an ECMAScript engine. This engine is extended by an ECMAScript extension module (the standardized version of the core JavaScript language) that is communicating with the device native environment through a ECMAScript extension library. This allows the ECMAScript environment to be extended with new classes and methods implemented in native code (rather like Java Native Interface, JNI in Java). The ECMAScript engine and ECMAScript extension module can be conditionally compiled into a build of a web browser on potentially any software platform. Once a build of a web browser has been created with the ECMAScript extension functionality enabled, then the ECMAScript environment can be extended by placing a specially written ECMAScript extension library in a certain directory on the electronic device along with a permissions file, which specifies which Web pages will have access to the extensions. The file is also important for security reasons.